\section{Axe statique (Vincent)}
\label{axe_statique}

Cet axe présente les concepts de l'application qui deviendront par la suite des
classes. Grâce au cahier des charges et à l'étude réalisée dans
l'axe fonctionnel (\ref{axe_fonctionnel}), nous allons tout d'abord dégager les
principaux concepts avant de modéliser l'application dans son intégralité.
\\

\Large \textbf{Remarque Importante}
\normalsize\\
\noindent\fbox{\parbox{\linewidth\fboxrule\fboxsep}{L'idéal serait de faire
une application complètement modulaire et réutilisable. Pour ce faire il
faudrait que chaque objet métier soit décrit de façon générique par une
interface, que les concepts généraux soient centralisés dans une classe
abstraite et que celle-ci soit spécialisée. Cette façon de faire devrait
systématiquement être employée même s'il n'y a qu'une seule classe
spécialisée, et ce dans le but de prévoir une future évolution. Toutefois,
par manque de temps, cette façon de faire a été uniquement déployée sur les
acteurs.}}

\subsection{Une première approche de haut niveau}

La première approche que nous pouvons avoir vis à vis du système ne peut-être
qu'une approche de haut niveau. Celle-ci consiste à se poser la question
suivante : \emph{Quels sont les grands composants de l'application ?}

\subsubsection{Les données}

Le cahier des charges nous décrit avec précisions les données qui seront
manipulées par le système. Un premier composant pourra donc représenter
l'intégralité des données représentées par le système. 

\subsubsection{La persistance des données}

Nous sommes encore dans la modélisation mais nous savons déjà que des objets,
que ce soit en Java, en C\# ou bien en Python ne sont pas persistants et
disparaissent à la fin du programme. Il faut donc introduire un composant
chargé de rendre persistantes les données.

\subsubsection{L'interface utilisateur}

Les utilisateurs auront besoin d'une interface homme / machine pour profiter du
système. Il faut donc introduire ce composant. 

\subsubsection{Le contrôle des données}

Rappellons que notre application doit être modulaire et évolutive. Pour cela
nous devons découpler la vue des traitements qu'elle effectue sur les données.
Pour cela nous allons créer un nouveau composant qui sera chargé de faire le
lien entre la vue et les données : le contrôleur. 

\begin{figure}
\includegraphics[scale=0.5]{img/uml/static/high_level_packages.eps}
\caption{Diagramme de paquetages de haut niveau}
\end{figure}

\newpage
Ce premier diagramme comporte des paquetages que nous n'avons pas détaillés :

\begin{description}
\item[util] : paquetage qui contiendra des utilitaires divers n'ayant pas de
rapport direct avec l'application.
\item[exception] : paquetage contenant les exceptions que l'application sera
susceptible de lever.
\end{description}

De plus nous avons choisi de représenter ici les première classes qui seront
mises en œuvre lors du lancement de l'application :

\begin{description}
\item[SuperplanningGUI] : c'est la classe comportant le programme principale ;
\item[LoginController] : c'est le contrôleur permettant de gérer la connexion au
système
\item[Login] : c'est la classe qui sera chargée d'effectuer l'authentification
auprès du système. Une fois cette authentification faite, l'utilisateur sera
connecté au système.
\end{description}

\subsection{Modélisation des données et des services}

Les données sont les premières informations auxquelles nous sommes confrontés.
C'est donc la raison pour laquelle celles-ci sont modélisées au début de
l'analyse statique. Les données étant souvent complexes, il est necessaire
de réaliser pour chaque groupe de données (regroupées dans un paquetage)
une interface permettant de les manipuler simplement. Nous introduirons donc ce
point aux diagrammes suivants. 
Pour réaliser ces diagrammes nous nous basons sur un document : le cahier des
charges (cf. \ref{description_concepts}). 


\subsubsection{Les acteurs}

Les utilisateurs du système peuvent-être regroupés dans un premier paquetage :
celui des acteurs et des concepts très proches (comme le type d'une personne).

\begin{figure}
\includegraphics[scale=0.5]{img/uml/static/actor.eps}
\caption{Diagramme de classes du paquetage actor}
\end{figure}

\newpage

\subsubsection{Le contrôle d'accès}

Le contrôle d'accès regroupe les droits associées aux utilisateurs et la gestion
de ceux-ci.

 \begin{figure}[!h]
\center
\includegraphics[scale=0.5]{img/uml/static/administration.eps}
\caption{Diagramme de classes du paquetage administration}
\end{figure}

\subsubsection{Les études}

Ce paquetage ci dessous regroupe tous les éléments permettant de décrire les
études dans une université : étapes, fillières, départements, promotions\ldots

 \begin{figure}[!h]
\includegraphics[scale=0.5]{img/uml/static/study.eps}
\caption{Diagramme de classes du paquetage study}
\end{figure}

\newpage

\subsubsection{Les ressources}

Toutes les ressources non humaines sont regroupées dans ce paquetage. Une autre
solution aurait consisté à considérer un enseignant comme une ressource et à le
placer dans ce paquetage.

\begin{figure}[!h]
\includegraphics[scale=0.5]{img/uml/static/resources.eps}
\caption{Diagramme de classes du paquetage resources}
\end{figure}

\newpage


\subsubsection{Les évènements}

Pour gérer la planificiation d'un cours, ou d'un évènement en général nous
créons un paquetage évènement.

\begin{figure}[!h]
\includegraphics[scale=0.5]{img/uml/static/event.eps}
\caption{Diagramme de classes du paquetage event}
\end{figure}

\newpage

\subsubsection{Les contraintes}

Les contraintes de divers ordres spécifiées par l'enseignant responsable sont
regroupées dans un paquetage à part. Nous aurions pu choisir de mettre ces
contraintes dans le paquetage des évènements, mais si nous pensons aux
évolutions possibles de l'application, ce dernier choix n'est pas le plus
judicieux.

\begin{figure}[!ht]
\includegraphics[scale=0.5]{img/uml/static/constraint.eps}
\caption{Diagramme de classes du paquetage \emph{constraint}}
\end{figure}

\newpage

\subsection{Les relations de la couche métier}

Nous avons défini la composition de chaque paquetage de la couche métier et les
associations des classes d'un même paquetage. Revenons maintenant à un niveau
plus haut pour étudier les associations des classes de paquetages différents. 

\begin{figure}[!ht]
\includegraphics[scale=0.5]{img/uml/static/api_package.eps}
\caption{Diagramme de paquetages de la couche métier}
\label{diagramme_package_metier}
\end{figure}

\newpage

\subsection{Modélisation de l'IHM}

La modélisation des données n'est pas une étape compliquée une fois que le
cahier des charges a correctement été rédigé. Les étapes qui suivent demandent
un peu plus de réflexion car elles ont été moins préparées. Premièrement
étudions les besoins des utilisateurs en terme d'interface homme machine.

\subsubsection{L'authentification au système}

La cahier des charges mentionne que l'application doit être sûr et qu'un
processus d'authentification des utilisateurs doit-être mis en place.
Concrètement, cela se matérialise par une IHM de connexion permettant de saisir
son nom d'utilisateur et son mot de passe afin de se connecter au système. 

\subsubsection{L'administration des données}

L'interview avec l'expert métier ainsi que l'étude de l'axe fonctionnel nous
font prendre conscience de la nécessité d'avoir une interface permettant
d'administrer les données de l'administration. Celle-ci doit permettre la
visualisation, l'ajout, la modification ou la suppression des données
(personne, salle de cours, enseignement\ldots). Il est donc necessaire de
réaliser une classe représentant cette IHM.

\subsubsection{La visualisation des plannings}

Enfin nous avons besoin d'une interface permettant de visualiser les différents
planning proposés par l'application. Pour des raisons évidentes de modularité,
cette interface doit-être dissociée de l'interface permettant l'administration
des données. 

\emph{\underline{Remarque} : Cette partie pourrait-être gérée en Java, mais
nous avons fait le choix d'utiliser le framework \emph{Apache Cocoon} pour
représenter les données sous la forme de pages HTML générées à partir de
documents XML}

\begin{figure}[!ht]
\includegraphics[scale=0.5]{img/uml/static/gui.eps}
\caption{Diagramme de classes du paquetage gui}
\end{figure}

\newpage

\subsubsection{Modélisation des contrôleurs (du modèle MVC)}

Nous avons à présent modélisé les données, les services proposés sur ces données
ainsi que les IHMs. Nous devons maintenant définir les classes qui permettront
d'interfacer les vues avec le modèle. Il s'agit des contrôleurs du modèle MVC.
Ce patron de construction sera revu en détail dans le chapitre concernant
l'implantation. Du point de vue de l'axe statique, les contrôleurs se
matérialisent par des classes qui ont une variable d'instance sur leur vue et
sur la ou les donnée(s) manipulée(s). Les contrôleurs doivent calquer la
structure des vues. Ainsi si une vue est composées de plusieurs éléments, on
pourra avoir un contrôleur composé de plusieurs sous contrôleurs : un pour
chaque sous vue. Une action sur le contrôleur principal sera alors redirigée
sur les contrôleur adéquat.

\begin{figure}[!ht]
\includegraphics[scale=0.5]{img/uml/static/controller.eps}
\caption{Diagramme de classes du paquetage controller}
\end{figure}

\pagebreak[9]

\subsection{Représentation d'une instance du système}

Maintenant que la structure statique de l'application est modélisée, il
peut être interessant de s'assurer qu'elle est correcte, et d'avoir un premier
aperçu des relations entre les instances des classes décrites. Pour cela nous allons
modéliser une instance \textbf{partielle} du système contenant
\begin{itemize}
  \item Un enseignant (\emph{Onurb}) et son droit d'accès (\emph{TeacherAccess})
  ;
  \item Trois promotions (\emph{L3INFO11, M1SIS11 et M1BIO11}) ;
  \item Deux étapes (\emph{L3 et M1}) ;
  \item Trois cours (\emph{I63, INF8, Anglais}) ;
  \item Un évènement (\emph{Vote}) ;
  \item Deux salles de cours(\emph{U004 et W07}) ;
  \item Deux bâtiments (\emph{Bât U, Bât W}).
\end{itemize}

Nous allons supposer le scénario suivant (\emph{seuls les points délicats sont
décrits})
: M. Onurb dispense des cours aux trois promotions. Le cours d'anglais est
commun aux promotions \emph{M1SIS} et \emph{M1BIO} et a donc lieu dans la même
salle (W07).Les L3INFO et les M1SIS ont un évènement non cours (donc non associé à une salle) de
programmé (ils doivent aller voter). 

\emph{Ce type de scénario est-il faisable ?} Nous allons le présenter puis
expliquer en se basant sur les diagrammes de classes les raisons de sa faisabilité.


\emph{Remarque} : \emph{TopCased} ne permettant pas de faire - à prioris - des
diagrammes d'objets, celui-ci a été fait de façon manuscrite.

\begin{figure}[!ht]
\includegraphics[scale=0.5]{img/uml/static/objects.eps}
\caption{Diagramme d'objets d'une partie d'une instance système}
\end{figure}

Étudions la validité de ce diagramme :
\begin{description}
\item[Plusieurs promotions par enseignant] : D'après la figure
\ref{diagramme_package_metier}, un enseignant peut-être associées à une ou
plusieurs promotions.
\item[Même évènement pour plusieurs promotions] : D'après la même figure
\ref{diagramme_package_metier}, une promotion est associée à un ou plusieurs
évènements et vice versa. Un même évènement (ou cours) peut donc être destiné à
plusieurs promotions.
\item[Une même étape pour plusieurs promotions] : Une étape est associée à
plusieurs promotions (l'association est même une agréation). Il n'y a donc aucun
problème ici.
\item[Idem pour le reste]
\end{description}

\emph{Nous avons réitéré ce même processus sur d'autres instances du système
pour s'assurer de la validité du modèle statique}.

\subsection{Représentation des composants du systèmes}

Les diagrammes de classes sont un bon moyen pour représenter les concepts et
leurs relations. Néanmoins, pour avoir les idées claires sur les différents
composants logiciels du système, normalisons les grâce au diagramme de
composants suivants.

\begin{figure}[!ht]
\includegraphics[scale=0.5, angle=90]{img/uml/static/components.eps}
\caption{Diagramme de composants du système}
\end{figure}

\newpage

\section{Déploiement du système}

Le déploiement d'un système consiste à mettre en place ses différents composants
afin qu'il puisse être utilisé dans son environnement final. Il permet de
définir les périphériques physiques étant mis en jeu (routeur, ordinateur
personnel, serveur etc.) ainsi les contraintes techniques liées au matériel.
Ce déploiement peut-être modélisé par le diagramme de même nom :

\begin{figure}[!h]
\includegraphics[scale=0.47]{img/uml/static/deployement.eps}
\caption{Diagramme de déploiement du système}
\end{figure}